home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1060 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-06  |  1.5 KB  |  34 lines

  1. >>>>> Steve Clamage <clamage@Eng.Sun.COM> writes:
  2.  
  3. > In article rp3@mozart.wg.icl.co.uk, Adel El-Beik <A.El-Beik@man0506.wins.icl.co.uk> writes:
  4. >> I have a question concerning MSVC++ v.4.00 and the April DWP C++.
  5. >> 
  6. >> The following code fails on MSVC++.  It doesn't like line labelled 1.
  7. >> It complains with 
  8. >> 
  9. >> C:\array\array.cpp(16) : error C2664: 'func' : cannot convert parameter 1 
  10. >> from 'long [2][2]' to 'const long [][2]' (new behavior; please see help)
  11.  
  12. > You have run into effectively the same rule that prohibits implicit
  13. > conversion from "T**" to "const T**". That prohibition is not new,
  14. > but is in the ISO/ANSI C standard, and has not been changed, since
  15. > it would open a hole in the type system.
  16.  
  17. But converting long (*)[2] to const long (*)[2] is more like converting
  18. long ** to const long *const * than it is like converting long ** to const
  19. long **, because there is no way to modify the array -- there is, in fact,
  20. no array entity in memory, only two longs.  A long (*)[2] points to two
  21. longs, whereas a const long (*)[2] points to two const longs.  I don't see
  22. a constness hole there.
  23.  
  24. I suspect this is an oversight.
  25.  
  26. Jason
  27.  
  28.  
  29. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  30. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  31. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  32. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  33. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  34.